1. Technical Field of the Invention
This invention relates to telecommunication systems and, more particularly, to a system and method in a General Packet Radio Service (GPRS) network for using a Gb interface, which has been modified to operate using the Internet Protocol (IP), to automatically configure Network Service Entity Identifiers (NSEIs) in a Base Station System (BSS) and a Serving GPRS Support Node (SGSN).
2. Description of Related Art
The Gb interface is an interface in the GPRS network between the between the SGSN and the BSS based on the connection-oriented Frame a Relay protocol. The protocol stack currently comprises an L1 physical layer (related to Frame Relay), a Network Service (NS) layer, and a Base Station System GPRS Protocol (BSSGP) layer. The NS layer is divided into two sub-layers. The upper NS sub-layer is called the Network Service Control (NSC), and is like the glue with the BSSGP layer above. The lower NS sub-layer is called SubNetwork Service (SNS), and is like the glue with the underlying Frame Relay structure. The structure and function of the existing layers is described in more detail below in connection with FIGS. 1 and 2.
It is desirable to replace existing interfaces in the GPRS network with connectionless Internet Protocol (IP)-based interfaces. Currently, for example, the interface between the SGSN and the Gateway GPRS Service Node (GGSN) is based on IP, and many of the network nodes operate internally on the IP protocol. Many advantages could be gained by converting the Gb interface to utilize IP also. A straightforward solution is to encapsulate the Frame Relay information in IP packets sent between the two nodes. However, this solution adversely impacts the performance of the Gb interface as described further below. Also, there are existing networks using the Gb interface over Frame Relay, and any new interface needs to be backward compatible to support these Frame Relay networks. Therefore, the new interface must have a protocol stack that supports both Frame Relay and IP. Thus, unlike other interfaces in the GPRS network, the Gb interface has not been converted to IP because there has not been a solution identified that supported both Frame Relay and IP while not adversely affecting the performance of the interface.
It would be advantageous to have an interface between the BSS and the SGSN that is based on the IP protocol. There is a larger pool of products available for IP than for Frame Relay, and the use of IP allows the use of several different layer 1 and layer 2 technologies (e.g., Frame Relay, Ethernet, fiber optics, etc.). In essence, the Gb interface would become carrier-independent and much more flexible in terms of routing. It would also be easier to maintain.
Basing the interface on IP would provide additional flexibility and features that exist in IP but not in Frame Relay. For example, an automatic configuration method would enable BSS components to be changed, or new BSSs to be added to the network while automatically configuring the SGSN to handle the new network configuration. In the existing Frame Relay-based Gb interface, information is carried between the nodes using virtual circuits. These connections must be established manually. The SGSN must know in advance which fimctional entity is going to be on the other side of each virtual circuit, so when there is a change to the BSS, a technician must physically go to the SGSN and enter the same data that was set up in the BSS. For example, identifying numbers are assigned to each functional entity, and the technician must manually deconflict these numbers by making sure that the numbers that he assigns in the BSS are not already assigned in the SGSN to other entities. When several groups of technicians are working on different nodes, all of which interface with the SGSN, it becomes a large coordination task to ensure that the identifying numbers are deconflicted, and the same numbers are not assigned by different groups to different functional entities. It would be desirable to have an automatic “plug and play” configuration methodology that would perform these tasks automatically.
There are no known prior art teachings or suggestions of a system and method such as that described and claimed herein.